1. Technical Field
The present invention generally relates to computer systems, specifically operating system software and device drivers, and more particularly to interrupt handling mechanisms for devices attached to multiprocessor operating systems.
2. Description of Related Art
As computer systems have evolved and become more complex, the use of multiple processors coupled by buses within a computer has increased. State-of-the-art multiprocessor network servers and dedicated desktop workstations are in common use.
Operating systems for use with multiprocessing systems have also grown in complexity, adding API""s (Application Programming Interfaces) in the operating system and support routines in the kernel of the operating system to provide information about the organization of the hardware of the computer system, and allowing control of the operating system in how it allocates tasks and resources to the processors and processes being executed by the processors.
Computer systems use device drivers to enable communication between hardware devices, such as storage devices, communications ports, network adapters, and so forth, and operating systems services and services that can be interfaced to applications software. A device driver is an installable module that contains instructions and data for controlling its particular device or multiple devices and connecting them with operating system services or application programs.
An attached or integrated piece of hardware known as an adapter may control and connect one or more devices. For example, in RAID (Redundant Array of Inexpensive Disks) array controllers produced by IBM (International Business Machines Corp.), the SCSI (Small Computer Systems Interface) adapters contain several devices, each controlling an individual SCSI bus, and each SCSI bus may connect a plurality of DASD""s (Direct Access Storage Devices).
Commonly, a hardware device will provide an interrupt so that it may request service due to stimulus from an outside source. For example, a serial port driver will commonly generate interrupts on the receipt of one or more bytes of data. In addition, interrupts are used to indicate to the device driver that the device has completed a command or other task that has been previously given to the device by the driver. For example, a SCSI controller may generate an interrupt when it has completed a read or a seek operation on a disk drive, so that the driver knows that data is present to be transferred, or the device is ready to execute the next command.
These interrupts originate as an electrical signal from the device and provided to the computer system, usually via an interrupt controller that is a circuit coupled to the computer bus to which the device is attached. This controller issues another signal to tell a processor that an interrupt is pending. Operating system code, typically provided by the kernel, changes execution. context (leaving the context of lower priority application code or kernel routines), and executes code that has been xe2x80x9cattachedxe2x80x9d to the interrupt by the device driver, known as an ISR (Interrupt Service Routine). This attachment often takes the form of an interrupt binding service provided by the kernel and called by the device driver during initialization.
When the interrupt service routine is executed, the device driver performs tasks associated with the interrupt. For example, the device driver will usually set or reset the hardware register responsible for generating the interrupt signal so that the interrupt will not be present upon exiting the ISR, which on some computer system/operating system combinations will result in the ISR being called again.
The ISR is typically executed at a very high priority within the set of tasks managed by the kernel of the operating system and it is not desirable to tie up the execution of the ISR with time-intensive tasks. Additionally, in some operating systems, certain services may not be available or may yield unstable results or system crashes if the service routines providing these services are called during the execution of an ISR. This allows the operating system to synchronize objects that may only be manipulated by lower priority tasks without having to block higher priority tasks to ensure that the objects are not corrupted by simultaneous execution of the services by multiple high priority tasks.
For this purpose, operating systems such as WINDOWS NT and WINDOWS 2000 (produced by Microsoft Corporation), provide an architecture that includes a deferred procedure call (DPC). This deferred procedure call can be queued by the ISR, and the operating system will call a routine associated with the DPC at a lower priority level, after the ISR has returned and other higher priority tasks in the system have been performed. The operating system can provide more services at this DPC level, since it is scheduled, and the operating system can delay the execution of the DPC to a greater degree than the ISR while still allowing for a higher execution priority than for example, application program code.
Typically, a device driver will create and initialize one DPC object and associated work list per interrupt that it uses. The DPC routine handles requests, command completions, and external communication responses for all of the devices supported by the interrupt. The interrupt signal line may be shared with other device drivers and devices, each driver having it""s own DPC and work list associated with the interrupt. Some device drivers that control devices that do not perform sequences of tasks do not require work lists, but queue DPC objects with the system and the DPC routine can interact with hardware or values stored by the ISR to complete DPC processing.
When multiple processors execute operating system and application code, tasks are generally apportioned to the processors based on processor availability. A scheduled DPC routine may be scheduled for more than one processor, and in some cases, it is up to the DPC routine to determine that the DPC is already being executed on another processor. It is also possible to xe2x80x9clockxe2x80x9d the queued DPC requests associated with a DPC object for execution on a single processor.
Locking the queued DPC requests has a disadvantage in that some devices may either momentarily or on-average receive more interrupt requests and generate more work list entries than others. For example, when a particular direct access storage device (DASD) is being accessed in a system that manages multiple DASD""s and interfaces, on a momentary basis, a majority of work items will be placed on the work list associated with that device. Locking the DPC object to one processor means that only that processor will be able to service this high priority task. If the DPC object is not locked, having only one work list available for servicing an interrupt associated with a device still limits the system such that only one processor at a time will be able to service that device, since the DPC routine will generally mutually exclude other calls while a first call is being handled.
Therefore, it would be desirable to provide a method and a multiprocessor computer system to balance the handling of work items associated with a device, so that the power of the multiple processors can be brought to bear on the queued work items. This would improve performance of the particular device for which the method is implemented and further the performance of the multiprocessor computer system, as DPC""s would be executed for high demand periods on multiple processors without waiting on a single DPC object and associated work list to be free. This would utilize idle time on processors that have no tasks scheduled, increasing overall system performance.
It is therefore one object of the present invention to provide a method to improve the performance of a multiprocessing computer system.
It is another object of the present invention to provide a computer system with improved deferred procedure call handling.
The foregoing objects are achieved in a method for balancing deferred procedure execution within a multiprocessor computer system that creates a set of DPC (Deferred Procedure Call) objects having a useable subset of DPC objects, executes an ISR (Interrupt Service Routine) in response to an interrupt from a device, then selects a DPC object from the usable subset of DPC objects, and queues a DPC associated with the device on the selected queue. The ISR may select a least-recently-queued DPC object.
The selection may be performed by masking a counter value with a mask that provides a range of output values for selecting a least-recently-queued DPC object and a least-recently-queued work list and then incrementing said counter value so that another queue and work list are specified for the next ISR. The mask may be created by determining the number of processors present in the computer system so that said usable subset of DPC objects has a quantity of DPC objects greater than or equal to the number of processors. The number of DPC objects created, however, may be equal to a maximum number of processors that may be installed in said multiprocessing computer system.
The multiprocessor system may be executing an operating system providing interrupt handling services, and the DPC may be queued by executing a call to a service provided by the operating system for queueing DPC""s, and the DPC""s may be created by calling the a service provided by the operating system for initializing DPC""s. The multiprocessor computing system may be coupled to a RAID (Redundant Array of Inexpensive Disks) subsystem and the creating, selecting and queuing of the DPC""s may be performed by a device driver associated with the RAID subsystem.
The method may be embodied in a multiprocessor computer system, or additionally in a computer program product having signal bearing medium containing program instructions for executing the steps of the method.
The above as well as additional objectives, features, and advantages of the present invention will become apparent in the following detailed written description.